Ok, sounds good! Please update this branch accordingly. Thanks!

Updated the branch. In addition, I realized that my changes in grabFame contained another logical error: I used the pkt.stream_index(-1) technique in doData processing part to guarantee that a new packet is read on the next grabFrame call. However, because of this trick, this Data packet is not unreferenced, which will leak memory. To solve this problem, I abandoned setting the pkt.stream_index to -1, and changed the condition for reading the new package to the following explicit one.
boolean readPacket = (pkt.stream_index() != video_st.index() && pkt.stream_index() != audio_st.index());
I think this is correct, since we need to try to reuse packets related only to the selected audio and video streams, in all other cases we need to read a new packet.

We can set stream_index to -1 any time we want, we just need to make sure to call av_packet_unref() before doing that, such as here: https://github.com/bytedeco/javacv/blob/master/src/main/java/org/bytedeco/javacv/FFmpegFrameGrabber.java#L714-L717
Could you try to do that instead?

But we just have set

// Export the stream byte data for non audio / video frames
frame.data = pkt.data().position(0).capacity(pkt.size()).asByteBuffer();
frame.opaque = pkt;

to return a frame with some data. Now if we call av_packet_unref() after it, what will be in the returned frame then?

Ah, yes, ok I see what you mean. So, readPacket is false on the first pass, but it gets set to true on the second pass here:

                if (!readPacket) {
                    readPacket = true;
                    continue;
                }

But you've removed that... why?

Well, because the logic including this part was initially incorrect.
First, if we get to the condition
} else if (doData) {
that means that all the previous if/else if were false, which means various variants, including when a packet (new or old) was from a stream different from the selected audio or video, OR it was from any stream not needed now (say, doAudio or doVideo is false). Then the doData handling part might return frame with data from ANY type of packet, not only data, subs or attachment.
So, I redesigned the condition for doData handling so that it to be explicit, so that it process only not audio and not video packets. In this new logic we need to read new packet if none of the specific if/else triggered - this is now done by the last else:
} else readPacket = true; //current packet is not needed (different stream index required)
And this is now the part which does the work corresponding to the previous code

                if (!readPacket) {
                    readPacket = true;
                    continue;
                }

So, now grabFrame correctly returns data packets if these packets are from data, subs or attachment streams only.
But at the next grabFrame call we must account for two things:

1. we have to read new packet, because the previously read data packet may trigger the condition
   } else if (doData && pkt_stream_ind > -1 && streams.length > pkt_stream_ind && streams[pkt_stream_ind] != AVMEDIA_TYPE_VIDEO && streams[pkt_stream_ind] != AVMEDIA_TYPE_AUDIO) {
   again and again
2. we have to unref previous data packet.

the fist task could be solved by setting stream index to -1 for that packet (as I suggested initially). But then it will not be unref. So we should retain its stream index as initial (this way the second task will be solved automatically if we set readPacket to true somhow - but how?). A possible way could be to check if frame.opaque is equal to the previous packet, and then to read new packet if it is true. But the frame.opaque may be changed in a user code (somewhere between two succeeding grabFrame calls) though. So I decided that the best way will be the change of the initial readPacket condition to the explicit form (we should try to reuse a previous packet for the selected audio and video streams only)

In general, this data processing problem occurs due to the fact that data is handled differently than audio or video. In the case of audio or video, we use the send_packet / receive_frame functions, which themselves suggest whether additional packets need to be read. In the case of data, we do not have such capabilities - we just have to return this data as frame.data and ensure that the new package is read on the next grabFrame call (and the old package is removed as well)

In general, this data processing problem occurs due to the fact that data is handled differently than audio or video. In the case of audio or video, we use the send_packet / receive_frame functions, which themselves suggest whether additional packets need to be read. In the case of data, we do not have such capabilities - we just have to return this data as frame.data and ensure that the new package is read on the next grabFrame call (and the old package is removed as well)

Right, the reason to use that block is precisely so that doData behaves like doVideo and doAudio. I suppose it doesn't work when doData is false, yeah. So maybe something like this?

            } else {
                if (!readPacket) {
                    readPacket = true;
                    continue;
                }
                if (doData ...
                }
            }

Yes, that should work correctly as well as the last suggested code in the framenumber branch. The only difference I can see is that processing data packets with

            } else {
                if (!readPacket) {
                    readPacket = true;
                    continue;
                }
                if (doData ...
                }
            }

will always require additional run of the external while(!done) loop to set readPacket=true, while in the case of

boolean readPacket = (pkt.stream_index() != video_st.index() && pkt.stream_index() != audio_st.index());

it is set true from the very beginning for any not video/audio packets. That can be slightly more efficient (but only in case of the data packets processing, which is not so often situation though). So now we have to determine which solution is the best.

Actually, something like looks more clean:

            } else if (readPacket && doData && whatever) {
                // ...
            } else if (!readPacket) {
                readPacket = true;
            }

That way, we don't have a continue out of no where, which makes it clear that readPacket is always going to be set and that we're eventually going to either process/return something, or reach the end of the file/stream.

Ok. I agree. But why should we check readPacket in the last else?

We don't need to, we can just force it to true, sure.